Press Room  |  Get Java Here  | 

Printed: Apr 30, 2025
From: http://www.jcp.org/en/jsr/detail?id=133

Standard Format

Specification Leads
	William Pugh	Pugh, William
Expert Group
	Adve, Sarita	Hewlett-Packard	IBM
	Lea, Doug	Oracle	Pugh, William

Updates to the Original Java Specification Request (JSR)

The following updates have been made to the original JSR.

2.11 Please describe the anticipated schedule for the development of this specification.

It is intended that this JSR will be delivered as part of the J2SE^TM "Tiger" release.

2004.10.01:

Specification Lead: William Pugh

E-Mail Address: pugh@cs.umd.edu

Telephone Number: +1 301 405 2705

Fax Number: +1 301 405 6707

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Tim Lindholm

E-Mail Address: Timothy.Lindholm@sun.com

Telephone Number: 408-343-1441

Fax Number: 408-343-1482

Specification Lead: Tim Lindholm

E-Mail Address: Timothy.Lindholm@sun.com

Telephone Number: 408-343-1441

Fax Number: 408-343-1482

Note that this information has been updated from this original proposal.

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

• Sun Microsystems
• Compaq
• IBM
• HP
• William Pugh, Univ. of Maryland
• Doug Lea, SUNY Oswego
• Sarita Adve, Univ. of Illinois at Urbana-Champaign

Section 2: Request

2.1 Please describe the proposed Specification:

The proposed specification describes the semantics of threads, locks, volatile variables and data races. This includes what has been referred to as the Java memory model.

The specification is expected to revise substantially Chapter 17 of "The Java Language Specification" and Chapter 8 of "The Java Virtual Machine Specification". It is not expected to result in changes to existing APIs, but might clarify the semantics of some existing methods in java.lang.Thread and java.lang.Object (java.lang.Object defines the wait and join methods).

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

All platforms.

Given that the Java programming language and Java virtual machine are affected, the revision must be accepted into an umbrella JSR for the J2SE platform for the changes to be made available.

Not all users of Java technologies will be directly affected by the change. For instance Enterprise Java Beans are constrained to be single threaded, so the revision is not expected to impact EJB developers (but is likely to impact developers of EJB containers, which are typically multithreaded).

2.3 What need of the Java community will be addressed by the proposed specification?

Users of the Java programming language need to be able to write reliable multithreaded software and understand which thread communication idioms are legal.

Java virtual machine (JVM) implementors need to be able to implement high-performance JVMs without violating the JVM specification.

2.4 Why isn't this need met by existing specifications?

Chapter 17 of "The Java Language Specification" (repeated as Chapter 8 of "The Java Virtual Machine Specification") currently specifies the semantics of threads and locks, as well as related features such as volatile variables.

Unfortunately, the current specification has been found to be hard to understand and has subtle, often unintended, implications. Certain synchronization idioms sometimes recommended in books and articles are invalid according to the existing specification. Subtle, unintended implications of the existing specification prohibit common compiler optimizations done by many existing Java virtual machine implementations. Enforcing these aspects of the specification would be prohibitively expensive on many existing processor architectures. It is doubtful that enforcement of these implications would be useful to programmers, regardless of the cost of enforcing them. Several important issues, such as the interaction between synchronization and final fields, simply aren't discussed in the existing specification.

2.5 Please give a short description of the underlying technology or technologies:

Goals of the specification revision:

• The semantics of "correctly synchronized" programs should be as simple and intuitive as feasible. Thus, "correctly synchronized" should be defined both formally and intuitively
• The semantics of incompletely or incorrectly synchronized programs should be defined so that such programs cannot be used to attack the security of a system
• Programmers should be able to create multithreaded programs with confidence that they will be reliable and correct
• High performance JVM implementations across a wide range of popular hardware architectures should be possible
• There should be minimal impact on existing code

• Volatile variables
• Final variables
• Immutable objects (objects whose fields are only set in their constructor)
• Thread- and memory-related JVM functionality and APIs such as class initialization, asynchronous exceptions, finalizers, thread interrupts, and the sleep, wait, and join methods of class Thread

• There exist a number of common but dubious coding idioms, such as the double-checked locking idiom, that are proposed to allow threads to communicate without synchronization. Almost all such idioms are invalid under the existing semantics, and are expected to remain invalid under the proposed semantics.
• Most programmers assume that immutable objects such as String do not need synchronization. Unfortunately, in an incorrectly synchronized program it is possible for a thread to observe a unsynchronized immutable object change. In particular, it is possible for a String to first appear to have the value "/tmp", and on later observation appear to have the value "/usr". This has clear and serious implications for security. We propose changing the semantics to allow for efficient immutable objects, even in the presence of data races.
• As part of this effort, we will document the potential implementation impact of proposed semantics. In particular, some proposed semantics may be more expensive to implement on processors with weak memory models or expensive synchronization.
• Some of the proposed revisions, particularly to the semantics of volatile and final variables, may require that JVM implementations be changed in order to be compliant with the new specification. However, some implementations have already been changed in anticipation of the proposed revision, and are likely to remain compliant under it.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

No -- no new APIs are anticipated; any clarification of existing APIs (e.g. java.lang.Thread) should not necessitate renaming them.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

Many of the most surprising behaviors of a multithreaded program can happen only on a shared memory multiprocessor with a weak memory model. The cost of strengthening the specification is anticipated to be highest on such systems, but should not preclude their effective use of Java technologies.

2.8 Are there any security issues that cannot be addressed by the current security model?

One issue to be addressed in the revised specification is that under the current specification, immutable objects (such as String instances) might be observed to change, potentially compromising security. This problem will be fixed in the proposed specification.

2.9 Are there any internationalization or localization issues?

No.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

Chapter 17 of "The Java Language Specification" and Chapter 8 of "The Java Virtual Machine Specification" are proposed to be revised substantially. Supplementary changes might be needed elsewhere in those specifications. Clarification to the specification for java.lang.Thread and java.lang.Object might also prove appropriate.

Such changes will strive to retain as clearly valid all patterns that are valid according to the existing specification and in significant use in deployed Java software. Thus, existing binary applications that exclusively make use of currently valid coding idioms should run unchanged. The effort will also attempt to make valid certain currently illegal idioms that are occasionally used nonetheless by the community, if it is possible to do so economically. Where that is impossible, the spec will clarify that the idioms are invalid and should not be used.

2.11 Please describe the anticipated schedule for the development of this specification.

Initiation: June 2001
Community Review: October 2001
Public Review: November 2001
Final Draft Proposal: January 2002

Note that this section has been updated since the original JSR.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

We anticipate a working style, if agreed upon by the expert group, that encourages review and feedback from outside the expert group as early in the process as feasible. Such a style will provide continuity with the efforts to date, which have taken place outside of the JCP.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Discussion of the issues in this JSR has been ongoing for some time. Some of this discussions have taken place on the Java Memory Model mailing list. The Java Memory Model web page (http://www.cs.umd.edu/~pugh/java/memoryModel) contains archives of those discussions, as well as links to related resources. Some of the relevant resources:

1. Fixing the Java memory model, Proceedings of the ACM 1999 conference on Java Grande, 1999 Pages 89-98. (Slides from talk) -- this paper sets out some of the problems with the existing specification, although the solution proposed in this paper has been found to be inadequate and it not recommended for consideration.
2. The Java Memory Model, Section 2.2.7 of Concurrent Programming in Java, 2^nd edition, Doug Lea, Addison Wesley, 1999
3. Proposed revision to Section 17.4, Wait Sets and notification, Doug Lea
4. JavaOne 2000 BOF on revising the Java Thread Spec
5. Improving the Java Memory Model with CRF, Jan-Willem Maessen, Arvind and Xiaowei Shen, Computation Structures Group Memo 428, MIT, 2000.
6. Multithreaded semantics for Java, by Jeremy Manson and William Pugh, available as UMCP CS Tech Report #4215.

A subset of this paper, Core Multithreaded semantics for Java, by Jeremy Manson and William Pugh, will appear at Java Grande 2001.
7. JDC bug # 4329831: Hotspot compiler does not respect existing Memory Model

3.2 Explanation of how these items might be used as a starting point for the work.

The work listed above could be used as contributions toward an initial draft. Where it falls short of stated goals or constraints, further work will be needed by the Expert Group to determine the best course of action.

Contact Us

© 2025, Oracle Corporation and/or its affiliates. Terms of Use. Privacy Policy. Trademarks